1. Technical Field
This disclosure relates generally to cryptographic protocols by which messages are exchanged over a network.
2. Background of the Related Art
Service-Oriented Architectures enable the creation of composite applications that are comprised of reusable, loosely-coupled service components. Using the Simple Object Access Protocol (SOAP), Service Oriented Architecture (SOA) clients can invoke web services built atop the eXtensible Markup Language (XML) without explicit support for a wide variety of transport protocols and formats. A SOAP facade that sits in front of a legacy service may be constructed to enable web service virtualization, where clients invoke a virtualized version of the underlying service, thereby mitigating the need to understand intricate details of the service's implementation.
Appliances built purposely for performing traditional middleware service oriented architecture (SOA) functions are becoming more prevalent in certain computer environments. For example, SOA middleware appliances may simplify, help secure or accelerate XML and Web services deployments while extending an existing SOA infrastructure across an enterprise. The move toward middleware appliances that are built for SOA functions purposefully is predicated, at least in part, by the observation that conventional software solutions have increased processing requirements of SOA-based payloads despite the broad functional platforms, flexibility and customization available in conventional software solutions.
The utilization of middleware-purposed hardware and lightweight middleware stacks can address the performance burden experienced by conventional software solutions. In addition, the appliance form-factor provides a secure, consumable packaging for implementing middleware SOA functions. One particular advantage that these types of devices provide is to offload processing from back-end systems. To this end, it is well-known to use such middleware devices to perform computationally-expensive processes related to security. Thus, it is known that these devices provide various security-related functions including, without limitation, message encryption and decryption, digital signature checking and verification, and the like.
Some encryption schemes, such as cipher block chaining (CBC), encrypt data in chunks (or blocks) of a given size. When the data to be encrypted does not fit within a certain block size, it is necessary to add “padding” to the last block being encrypted. During decryption, the padding is removed and verified. If the padding is invalid, some decryption processes throw an exception in the form of an error message or code.
It has been known for some time that some block ciphers used in this way are subject to a compromise, known as a “padding oracle attack.” An “oracle” usually is formed as an unintended side-effect of a normal processing function. A padding oracle is when an attacker uses the regular decryption function to distinguish between encrypted messages that have valid and invalid padding (even if neither type of message decrypts properly). In effect, the attacker misuses the decryption process to discover something about the plaintext form of the encrypted messages he is modifying. This type of attack typically works by exploiting the information revealed by error messages that are generated by the decryption mechanisms.
This attack typically works as follows. Consider two systems exchanging encrypted messages over a public network. An attacker captures one such message and wishes to decrypt it. For certain encryption schemes (such as those that use block-based techniques and that do not perform data integrity checks), the attacker can use the intended recipient of the message to help with this attack. To do so, the attacker makes small modifications to the captured message and re-transmits the modified message to the original recipient. The decryption process may detect an error, or it may succeed. If it succeeds, the recipient's next processing stage is likely to detect an error. The details of precisely what the error was, e.g., whether it was detected in the decryption process, or whether it was detected in a subsequent processing stage, and if so, the precise nature of the error, “leak” information about the decrypted data. The information that is leaked typically is a function of the original plaintext and the modifications performed by the attacker. For certain cryptographic modes used in the decryption process, this information leakage is such that, after a number of similar modifications and re-transmissions, the attacker may be able to determine the original plaintext content of the original message or even cause the oracle to decrypt messages (sent by the attacker) using the oracle's key. Thus, the fundamental weakness that the attack exploits is that useful information (namely, about errors in the decrypted data) is potentially revealed to the attacker.
The above-described problem is not limited just to padding schemes. While padding was the target of the earliest published form of the attack, the approach is more general in that it can target several different ways that a message can be malformed. Thus, a similar type of attack can be carried out whenever the recipient, in rejecting an encrypted message, reveals information about the type of problem that caused the message to be rejected, thereby allowing the attacker to make small changes to the message repeatedly and determine the effects of those changes via the error messages returned.
Avoiding such attacks would enhance a middleware (or other device) that provides such message processing capabilities.